Release 10.1A: OpenEdge Getting Started:
Core Business Services

Configuring additional user authentication systems and domains

Interwoven with data integrity in a successful auditing implementation is nonrepudiation. Nonrepudiation means that users cannot call into question their having performed an action if the action, in turn, generates a recorded audit event. Audit data that identifies what happened, where, and how is useful, yet incomplete if it fails to identify who performed the auditable application or database operation.

Each user ID specified in audit records must originate from a successful authentication to a user authentication system that OpenEdge trusts. It must be possible for the user’s authentication to be validated to ensure that the user ID was not compromised during transit from the authentication system to the database connection where the user ID is inserted into audit records. Only then can the user recorded in audit records be trusted to be accurate.

Previously, the only trusted user ID source for OpenEdge was the _user table. However, reliance on the _user table meant that it was not possible for OpenEdge to validate that a user ID from a 4GL application was coming from a trusted 4GL application source. At issue was how a 4GL application could use an external (to OpenEdge) authentication system and convey the resulting authenticated user ID to a 4GL client in a manner that ensured that OpenEdge can trust the user ID in audit records.

The solution is to allow a 4GL application to become a trusted source of user authentication. With the introduction of the new 4GL client-principal object and Trusted Application Domain Registry, OpenEdge can now establish a trust relationship with a 4GL application; the 4GL application will then be able to use its own authentication system, and OpenEdge will be able to accept as authentic all user IDs from that source.

User authentication based on the _User table (using the -U and -P parameters or the SETUSERID function) also remains valid and can be used as the user ID in the auditing records.

Note: For this version of OpenEdge, the _User table is still a requirement for authentication in SQL.

If you are connected as a database administrator, you can now do the following:

Define authentication type or types implemented within your 4GL applications.
Define authentication system domains that execute a particular authentication system at run time with your 4GL applications.

For the 4GL application to use its own authentication system (such as its own version of a _User table, perhaps), you must also make sure that:

The domain that originates a client-principal object is included in the trusted authentication domain registry.
The client-principal object is sealed, denoting a successful user authentication.

For more information, see Chapter 4, "Identity Management," and OpenEdge Development: Programming Interfaces .

Notes: If you continue to use the OpenEdge _User table for authentication, you need not do anything further to set up authentication. Connecting to an OpenEdge database by using either no ID or the user parameter (-U) and the password parameter (-P) is audited automatically when you have the audit service enabled.